


"Timetrav Encryption: A Brief FAQ" by cogitativeMistake

by lucidChthonia (liquidCitrus)



Category: Homestuck
Genre: FAQ, Gen, Replay Value AU, Time Shenanigans
Language: English
Status: Completed
Published: 2015-03-16
Updated: 2015-03-16
Packaged: 2018-03-18 03:21:12
Rating: General Audiences
Warnings: No Archive Warnings Apply
Chapters: 1
Words: 2,073
Publisher: archiveofourown.org
Story URL: https://archiveofourown.org/works/3554135
Author URL: https://archiveofourown.org/users/liquidCitrus/pseuds/lucidChthonia
Summary: <blockquote class="userstuff">
              <p>More than you probably ever wanted to know about Replay Value AU timetrav encryption!</p><p>Featuring answers to such questions as "Why do timetrav encryptions exist?", "What is the difference between a loose timetrav and a tight timetrav?", and "Can you use timetrav encryption together with regular encryption? Is that secure?"</p>
            </blockquote>





	"Timetrav Encryption: A Brief FAQ" by cogitativeMistake

### Why do timetrav encryptions exist?

Because Paradox Space is nonlinear. Although a sort of informal pseudotimeline can sometimes be inferred from Skaia’s concept of circumstantial simultaniety, this pseudotimeline only anchors on the great, plot-turning events that define a session (leaving plenty of room for lesser annoyances with nonlinearity in online chats and across sessions), is not comprehensible to the vast majority of Players, and is not amenable to Player intervention.

Thus, unless a timeline is manually enforced by a Time player or directional (non-anchored) encryption, intersession communication will be at best difficult or incomprehensible, and at worst actively catastrophic.

### How does directional encryption work?

Simplified version: The client - that’s you, usually - generates a new keypair (lock and key) for each message. You lock up each message you send to the server in a new lock, keep all the keys, and then try every key on every locked message on the server; only locks that you have the keys for will open. This is also sometimes called non-anchored encryption because it does not depend on a Time player “anchoring” the two timelines to each other.

As everyone who has tried to enforce a password system on their Time player will know, this is finicky and difficult to extend to multiple people at once. However, it is often sufficient for multiple people in the same session (for whom keysharing is simple and linear) unless your Time player actively decides to sabotage this linearity.

Sharing keys across sessions invokes the problems with Paradox Space having many timelines and these timelines not necessarily being linear to each other, so this isn’t a scalable solution. Some servers have tried doing multiparty directional encryption, which only a Time player could comprehend so I won’t even try describing how it works; suffice it to say that the calculations required to sync up the sharing of keypairs are generally prohibitive and significantly restricted the growth of Replayer networks before timetrav encryption was discovered and implemented.

### How does “anchored” (Time-player-enforced) timetrav work?

Time players can use their Time powers to grab hold of two timelines and mark events that should be synchronized together on these timelines, and thus either force or coax the timelines into alignment (depending on the Time player’s title). Most Time players with any experience will be able to do this for two or three timelines; however, with some titles (the Creative, Performer, and Destroyer classes) it is possible to extend this control over a large multitude of timelines. Your average post-Denizen Prince of Time will be able to maintain linearity across approximately three dozen timelines without compromising in-session effectiveness; a Muse of Time sometimes becomes _more_ efficient the more timelines they’re holding together (and thus facilitating contact between).

Because holding together timelines this way - serving as an “anchor” to maintain a timetrav encryption - is a cost-effective and constant source of ARC that “bears interest” (as it were), maintaining a timetrav is thus an attractive proposition even for Time players who otherwise would be perfectly okay with nonlinear communications.

### I understand how the Creative and Performer classes can get ARC for timetrav encryption, but why is it also ARCful for Destroyers?

A properly maintained timetrav will _restrict_ information to flow in one way: from the consensus past into the consensus future. This prevents the consensus future from affecting the consensus past.

In some cases, people have complained that it prevents future versions of you from sending messages to past versions of you specifically to avert events, or the equivalent across timelines. (If you want a headache, you can go ahead and try thinking about that. If you don’t, just don’t go there.) However: We cannot specifically automate only sending “important” messages backwards through the timetrav tunnel. “Important” is relative: if future you wants to be an asshole they can start sending you frivolous “important” messages. If you block them to try to retain some semblance of your sanity, then we’re back to the case mentioned before: not having any backwards movement of information.

The reason most people assume that timetravs increase information flow is because most Players are more willing to share information if they don’t have to run into massive headaches trying to understand the wibbly-wobbly. So while in most cases timetravs actually increase cross-session cooperation, they do this by restricting information flow and thus are technically a “destruction” of information using time. (Or a destruction of time shenanigans.)

### What is the difference between a loose timetrav and a tight timetrav?

Assuming you passed elementary algebra, the difference between a loose timetrav and a tight timetrav is a bit like the difference between a relation and a function.

A loose timetrav is a timetrav encryption that grabs hold of two timelines only via important events (from what Elizabeth has told me, “important” is approximately equivalent to whether something is an XP action in the system she’s using). Thus, if important events are more frequent in one timeline as opposed to another, the “dense” timeline will thus move at the same _circumstantial_ speed - speed of events - as the “sparse” timeline, but the exact ratio of time between the two timelines can vary wildly. This kind of timetrav encryption is enough for approximate linearity of asynchronous communication (such as forums and email) where a difference of several minutes is unimportant; however, synchronous communication such as chatrooms will still show up slightly nonlinearized because individual chat messages do not usually qualify as “important events”.

A tight timetrav is a timetrav encryption that grabs hold of timelines continuously; it thus enforces a simple linear ratio (often 1:1) between time passing on each timeline it is grabbed to. This makes it possible to engage in some types of synchronous communication, such as chatrooms; subsecond accuracy of transmission is often enough as long as the main bottleneck is typing. However, the pluck cost of maintaining a tight timetrav is significantly greater; this is why most early standards used loose timetravs and even the Sburb.org hybrid timetrav system (described in more detail below) tries to keep its subscribers on loose timetrav most of the time.

It is notionally possible to facilitate a “hypertight” timetrav that is accurate down to microseconds (such that it is possible to have synchronous voice and video chats), but the pluck cost for this is generally prohibitive and thus it is not used outside of extremely specific and limited instances.

### Hey, that doesn’t make sense. If we have to use radio waves to connect to servers using streams of packets, that implies that there’s a miniature hypertight timetrav around each stream of data denoting a “file” or “webpage”, so all you’d have to do to make a hypertight timetrav for video conferencing is to crank up your video quality to maximum and keep the data flowing!

Firstly, that isn’t a question.

Secondly, linearity for individual transmissions of a very short duration is generally an implicit or explicit clause in most Ring deals for server stability.

Thirdly, the maximum filesize for these “linearity implied” transmissions is something like a megabyte. Plenty for text, pushing it for pictures, and video and programs _have to_ be broken down into chunks that can be downloaded out of order like torrent files.

Finally, essentially all Skaianet networking software contains provisions for caching data that it receives unexpectedly, such that if you receive files before you request them, you don’t actually get shown this until you request said data. (The existence of this cache is exploitable if you are extremely good at hacking.) This hides the fact that many transmissions arrive out of order from the end user.

### What are “handles”, and why do I see people arguing about how many Time players “have” them?

A single “handle” is the local terminology for a block of users that are assigned to a Time player to keep together. Overlapping these handles such that each player is linearized by at least two or three Time players is generally considered best practice.

However, smaller timetrav encryption standards have gotten away with having single Time players assigned to them. This is not considered wise - people may be thrown back into Loose Replaying (with the capital L Loose this refers to being relegated to nonlinearized play again, thus being cut off from your community for what could well be _forever_ ) if the Time player assigned to a handle abruptly dies. Until Sburb.org’s Seer Network discovered “dongle scrying” (which is a misnomer; it should be called “timetrav connection scrying”), it was difficult to check how many Time players were involved in helping linearize you.

With the death of the Seer Network dongle scrying permissions became much more restricted (and even banned on some servers), but they are still useful for transparency purposes in circumstances such as these, which is the only reason it isn’t considered best practice to ban dongle scrying completely. But that’s a tangent.

### Why can’t people sign up for multiple timetrav encryption standards at the same time? / How do you transfer between timetrav encryptions?

Because they’re not generally compatible. Loose timetravs set performance targets for average server-to-client ratios that differ from timetrav to timetrav, tight timetravs may have different server-to-client ratios, and it is best not to talk about the bad interactions that happen when you try to attach a loose and a tight timetrav to the same person.

The best-case scenario, if you try to sign up for multiple timetravs without letting both of them know, is that the Time player on the second timetrav gets a backlash headache from trying to connect to your handle and writes you a strongly worded letter. The worst-case scenario is that there is destructive interference and you get cast off Loose.

You generally have to let both timetravs know you’re transferring; they can then step you down to a 1:1-ratio tight timetrav and hand you off that way to minimize adverse effects. You will then be stepped back up to the server-to-client ratio the timetrav uses, your timetrav will be loosened if necessary, and you’ll get assigned to handles.

### Can you use timetrav encryption together with regular encryption? Is that secure?

As even the staunchest of Time players cannot bear the number of unstable loops required to complete an NP-hard factorization problem due to the fact that it results in Veil-meteor-sized piles of doomedselves, public-key encryption ca. 2020 remains secure and, when layered inside a timetrav, makes access near-impossible (why this is “near” and not actual impossibility is described below) for those who are not supposed to see.

There have been isolated instances of Denizens or Others allowing access to individual encrypted posts or threads with Deals. The price of such a Deal tends to be outside the reach of those who wish to use it for harm (although this is a tendency, not an absolute), and more accessible (but still an arm and a leg) to those who request decryption for noble purposes. It is unknown how the Others and Denizens crack such encryption; theories generally center around the fact that both classes of beings seem to be outside Time somehow.

### How does Sburb.org’s hybrid timetrav work?

Sburb.org’s timetrav is “hybrid” in that it keeps people on a loose timetrav most of the time, but automatically switches you into a tight timetrav if you wish to log onto the IRC chat. It will then switch you back to loose when you log back out. In addition, you can pick your target average server-to-client ratio, if you wish. (I just leave it on the 1:1 default. It hasn’t served me wrong yet.)

This is achieved via having the timetrav connections routed through a highly specialized piece of phlebotinum technology that automatically manages the output of Time-energy to each individual connection, thus eliminating the need for the Time player in question to manage it herself. (The plans for this technology are available, but it is so immense and difficult to construct that the Sburb.org dedicated null session is the only place where it has ever been built in full.)

Incidentally, this is why it is technically against the rules to idle in the IRC chat for long periods of time without participating; you’re increasing resource load on artisticHourglass. (Yes, she’s an _actual person_.) In practice most people are allowed about two days’ worth of idling at a time, and anyone who participates regularly and is helpful can pretty much stay connected forever if they’d like.

**Author's Note:**

> I make some unavoidable assumptions about the "economics" of maintaining timetrav encryptions; I am not actually sure Aradia could keep even _two_ timelines lined up without sacrificing effectiveness. It has to work out this way in order to result in the Replay Value AU we know and love. If timetrav encryptions didn't have a "return on investment" for Time players, they wouldn't be nearly as widespread, and if one Time player couldn't keep together several dozen timelines, timetravs wouldn't be big enough to cover communities of thousands of people. Such is AUing for you, I suppose.
> 
> This was originally written for my blog _[A User's Guide to the Apocalypse](http://eternity-braid.tumblr.com/)_ , which is where I'm writing a conversion of Replay Value AU to an idiosyncratic diceless tabletop RPG system called _Chuubo's Marvelous Wish-Granting Engine_ , which is the only tabletop RPG I've seen that actually encourages slice of life interactions mechanically! (Plus the sourcebook has an epub version available for $10. No, that's not a typo.) If you are familiar with Replay Value AU it should be fairly obvious why it fits. I'll try to repost big works of fiction that fit especially well with Replay Value AU (like this one) back to AO3, but you'll find much more there!


End file.
